This invention relates to object-oriented systems utilizing inter-process pinging methods.
In multi-process computer systems it is desirable to provide facilities for allowing one process to utilize the resources of another process. The process using the resources is referred to as a client process and the process providing the resources is referred to as a server process. In many cases, a particular process might be both a client process and a server process, in that it uses the resources of other server processes while also providing resources of its own for use by other client processes.
It is also desirable to provide a standard interface mechanism between processes so that application programs from different vendors can conveniently share resources using a common protocol. One type of such interface mechanisms utilizes the concept of xe2x80x9cobjectsxe2x80x9d and xe2x80x9cobject interfacesxe2x80x9d to specify interactions between computers. An object in this environment is a unit of functionality that implements one or more interfaces to expose that functionality. An interface is a contract between the user, or client, of some object and the object itself. In more practical terms, an object is a collection of related data and functions grouped together for some distinguishable common purpose. The purpose is generally to provide services to client processes. An interface is a grouping of semantically related functions through which a client process can access the services of the object.
The invention described below has been implemented in a Microsoft Windows NT(copyright) programming environment using features of Object Linking and Embedding (OLE). OLE is based on a protocol referred to as the Component Object Model (COM). COM specifies how objects interact with each other using interfaces. OLE and COM have been well documented and will not be explained in detail here except for general concepts which are particularly pertinent to this invention. For more information regarding OLE and COM, refer to xe2x80x9cOLE 2 Programmer""s Referencexe2x80x9d and xe2x80x9cInside OLE 2,xe2x80x9d both published by Microsoft Press of Redmond, Wash., and both of which are hereby incorporated by reference.
In the COM environment, an interface is a block of memory containing an array of function pointersxe2x80x94that is, a function table. Through a standard object interface referred to as IUnknown, a client process can obtain a pointer to any interface supported by an object. When such an interface pointer has been obtained, it is said that the client process has obtained an interface on the object. The pointer does not provide access to the entire object; instead, it allows access to one interface on that object.
Objects and their interfaces are conventionally illustrated as shown in FIG. 1. A circle is used to represent each interface.
The services or functions of an object can be used by both in-process clients and by out-of-process clients. In addition, an interface can be used by a client executing on a different computer. The COM protocol covers all of these situations. Calling a remote interface (one that is in a different address space than the calling process) requires the use of xe2x80x9cstubsxe2x80x9d and xe2x80x9cproxies,xe2x80x9d and involves topics such as xe2x80x9cmarshallingxe2x80x9d and xe2x80x9cunmarshallingxe2x80x9d of procedure parameters. These mechanisms are well understood and are documented in the books mentioned above. In regard to these topics, also refer to xe2x80x9cX/Open DCE: Remote Procedure Call,xe2x80x9d published by X/Open Company Ltd., U.K, which is also incorporated by reference.
Objects must be instantiated in memory before they can be used. Once instantiated, they must be kept alive (remain in memory in a running or active state) until they are no longer needed. To maximize available memory, it is desirable to destroy objects (remove them from memory) and their interfaces when they are no longer needed. In order for the server process to keep track of when it is safe to destroy an object, COM implements reference counting. Through reference counting, a server object can keep track of whether any clients are still holding one or more interfaces on a server object. A client process is said to be holding an interface if it has obtained a pointer to the interface (usually by calling QueryInterface, a method of the IUnknown interface) and has not released it (by calling Release, another method of the IUnknown interface). An object must be is kept alive if there are one or more client processes holding one or more interfaces on the object. Reference counting involves simply incrementing a variable every time a pointer to an interface is obtained, and decrementing the variable every time a pointer to the interface is released. In some cases (such as in OLE), the practice is to maintain a single variable for an objectxe2x80x94the single variable is incremented or decremented regardless of which interface on the object is obtained or released. Other operating systems might maintain an individual variable for each interface so that the resources associated with an individual interface can be destroyed apart from the associated object. In this case, an interface is destroyed if its reference count goes to zero. An object is destroyed when all its interfaces have been destroyed.
Although reference counting works well in theory, it assumes that all client processes are well behaved and that they cooperate properly with reference counting procedures. However, this is not always the case, and it is not uncommon for a client process to somehow neglect to release an interface. This can happen through software design error or through hardware failure. Instances of this problem are even more frequent in multi-computer environments, where client and server processes reside on different computers. A failure in the client computer or in communications channels can make it impossible for a client process to notify the server process that it has released an interface.
In order to deal with this potential problem, some computer network systems employ what is referred to as xe2x80x9cpinging.xe2x80x9d Periodically, at selected ping periods, every client process that holds an interface on an object sends a keep-alive signal to the interface. As long as the interface continues to get keep-alive signals, the server process will keep the interface alive. After a pre-defined time without receiving a keep-alive signal, the server process will assume that there are no surviving client processes needing the interface, and the interface will be destroyed. The object with which the interface is associated will be destroyed only if all of its interfaces are destroyed.
The combination of reference counting and pinging would be effective except that pinging puts a tremendous load on computer resources and inter-process communications facilities. This is because of the great number of interfaces which might be implemented by a particular object and the potentially large number of client processes which might hold such interfaces. It would not be unusual for an object to receive 1000 periodic keep-alive signals. Regardless of the communications medium used, this would impose a large overhead on the system.
The invention provides several improvements which, together, make pinging techniques much more practical than they have been in the past. In one aspect of the invention, keep-alive messages between individual pairs of client and server processes are coalesced into single, inter-process messages to reduce communications overhead. In a further aspect of the invention, each client process registers with a ping manager, and the ping manager sends the appropriate keep-alive messages while monitoring its registered client processes to determine whether they are still executing.
A still further aspect of the invention involves client-side ping managers and server-side ping managers. Each client process registers interfaces it is holding with a client-side ping manager. Server processes register with a server-side ping manager. Each client-side ping manager periodically sends messages to the server-side ping manager indicating any registered interfaces held by registered client processes. With this information, the server-side ping manager keeps track of whether any client processes hold interfaces for a particular object, and notifies the server processes if they do not. As an improvement on this aspect of the invention, the server-side ping manager implements an object interface which can be accessed by the client-side ping manager to maintain a set or list of interfaces registered with the client-side ping manager. Rather than periodically sending a complete list of such interfaces, client-side ping manager needs only to send changes to such information to the server-side ping manager, while the server-side ping manager stores and monitors the list. The client-side ping manager periodically sends a keep-alive signal to the server-side ping manager through its object interface. If such a keep-alive signal is not periodically received, the server-side ping manager assumes that the interfaces registered with the client-side ping manager are no longer needed and destroys the list which was formerly stored on behalf of the client-side ping manager.